Dias-dynamic impu assignment service

ABSTRACT

A method and arrangement in a multimedia gateway connected to a multimedia service network, for providing access to multimedia services for communication devices connected to a private network. In the multimedia gateway, a communication unit receives a request from a device in the private network for a public identity associated with the multimedia gateway. An identity manager then selects and allocates an associated public identity from a pool of public identities associated with the multimedia gateway which have been predefined as valid in the multimedia service network. The communication unit then registers the device by activating the allocated associated public identity in the multimedia service network. Thereby, the multimedia gateway can establish a multimedia session on behalf of the device, using the allocated associated public identity.

TECHNICAL FIELD

The present invention relates generally to a method and arrangement forenabling multimedia communication by means of a multimedia gatewayconnected to a multimedia service network. Access to multimedia servicescan then be provided for devices connected to a private network,particularly different types of communication devices in a residentialnetwork.

BACKGROUND

Various communication devices are available today that are capable ofpacket-based multimedia communication using IP (Internet Protocol), suchas either fixed or mobile computers and telephones. Multimedia servicestypically entail transmission of encoded data representing media indifferent formats and combinations. The term “multimedia” will be usedin this description to generally represent any choice of mediacommunicated by using the packet based IP (Internet Protocol) transporttechnology. Multimedia services involve packet-switched communication ofdata representing different types of media, such as audio, video,images, text, documents, animations, etc.

A network architecture called “IP Multimedia Subsystem” (IMS) has beendeveloped by the 3^(rd) Generation Partnership Project (3GPP) as an openstandard for handling multimedia services and sessions in the packetdomain. IMS is a platform for enabling services based on IP transport,more or less independent of the access technology used and notrestricted to any specific services. Thus, an IMS network controlsmultimedia sessions but is not used for the actual transfer of payloaddata which is routed over access networks and any intermediate transportnetworks including the Internet.

FIG. 1 is an exemplary schematic illustration of a basic networkstructure for providing multimedia services by means of an IMS servicenetwork. A mobile terminal A is connected to a radio access network 100and communicates with a fixed terminal B connected to another accessnetwork 102, in a communication session S involving one or moremultimedia services. There may also be an intermediate backbone networkas well, not shown, linking the access networks 100 and 102.

An IMS network 104 is connected to the radio access network 100 andhandles the session with respect to terminal A, where networks 100, 104are typically owned by one operator. In this example, a correspondingIMS network 106 handles the session on behalf of terminal B, and the twoIMS networks 104 and 106 may be controlled by different operators.Alternatively, two communicating terminals may of course be connected tothe same access network and/or may belong to the same IMS network.Terminal A may also communicate with a server instead, e.g. fordownloading some media from a content provider. Moreover, if a terminalis roaming in a visited access network, multimedia services are handledby the terminal's “home” IMS network, i.e. where it is registered as asubscriber.

The session S shown in FIG. 1 is managed by specific nodes in each IMSnetwork, here generally referred to as “session managing nodes” 108.These nodes typically include S-CSCF (Serving Call Session ControlFunction), I-CSCF (Interrogating Call Session Control Function) andP-CSCF (Proxy Call Session Control Function). Each IMS network 104,106also includes one or more application servers 110 for enabling variousmultimedia services. Further, a main database element HSS (HomeSubscriber Server) 112 stores subscriber and authentication data as wellas service information, among other things. IMS network 106 is basicallysimilar to network 104. The various specific functions of the shownnetwork elements 108-112 are generally known in the art, but are notnecessary to describe here further to understand the context of thepresent invention. Of course, the IMS networks 104,106 contain numerousother nodes and functions not shown here for the sake of simplicity.

A specification called “SIP” (Session Initiation Protocol, according tothe standard IETF RFC 3261) is used for handling sessions in IMSnetworks. SIP is an application-layer control protocol for signalling,to create and generally handle sessions over a packet-switched logic.The SIP standard can thus be used by IMS systems and terminals toestablish and control IP multimedia communications. SIP itself does notprovide multimedia services, but rather makes available a set ofprimitives that other protocols or applications can use to actuallyimplement such services. For example, a message called “INVITE” isdefined in SIP to initiate a session during a set-up procedure, when acertain application has been invoked.

In SIP, an additional protocol is used called “Session DescriptionProtocol SDP”, for describing multimedia sessions, which can be embeddedas a self-contained body within SIP messages. SDP can thus be used byterminals to provide information regarding their specific capabilitiesand preferences, in order to negotiate and agree on which sessionparameters, in particular codecs as well as an IP address and port formedia, to use during a forthcoming multimedia session, as is well-knownin the art. The above-mentioned SIP INVITE message includes the SDP withinformation on one or more required codecs (coders/decoders) and othercommunication parameters needed for the forthcoming session.

According to 3GPP, it is required that a subscribing communicationterminal accessing an IMS network has access to an IMS SIM or “ISIM”(IMS Subscriber Identity Module) application, in order to providenecessary authentication and subscriber data to an operator of the IMSnetwork. Today, only IMS enabled terminals are allowed to access an IMSnetwork.

An ISIM application is typically installed on a Universal IntegratedCircuit Card (UICC), analogous to the well-known SIM card for GSMterminals. Terminals equipped with ISIM are referred to as “IMS enabled”terminals. Among other things, an ISIM stores an IMS Private Identityreferred to as “IMPI” and at least one IMS Public Identity referred toas “IMPU”, which are both known to the IMS network. IMPI is used forauthentication and is not to be disclosed to third parties, whereas IMPUcan be used by anyone to identify subscribers and/or their equipmentwhen participating in IMS services, as analogous to an e-mail address ora telephone number. The intention is that each IMPU is associated withan IMS service profile.

While the IMS concept was primarily conceived to enable multimediaservices for mobile IP terminals, it can be used regardless of accesstechnology, as mentioned above. In the European TelecommunicationsStandards Institute (ETSI), a working group called TISPAN (Telecom andInternet Services and Protocols for Advanced Networks) is currentlyworking with the adoption of IMS in fixed networks. It is now alsodesirable to provide such IMS-based services for a variety of IPterminals connected to a local or private network, particularly aresidential or office network environment using, e.g., conventional LAN(Local Area Network) equipment and protocols. The generic term “privatenetwork” will be used in the following description to represent any suchnetworks, including LAN, WAN (Wide Area Network) and WLAN (WirelessLocal Area Network). Further, the term “device” will be used for anyterminal in the private network capable of IP communication.

A private network may include fixed or wireless communication devicesthat are not IMS enabled, even though they may be “SIP enabled”, whileother communication devices in the private network may be neither IMSenabled nor SIP enabled. For example, such plain devices may includefixed and cordless telephones, as well as PC's and so-called STB's (SetTop Boxes) for television sets. The large amount of such existing “homedevices” makes it desirable to provide for an inter-working solutionbetween non-IMS devices and the IMS network, to enhance the market formultimedia services.

In order to provide IMS services to non-IMS enabled communicationdevices, e.g. connected to a private residential or office network, amultimedia gateway referred to as a “Home IMS Gateway HIG”, has beendefined that can act as an IMS enabled terminal on behalf of anycommunication device connected thereto. This type of Home IMS Gateway isdescribed in applicant's earlier patent application PCT/EP2005/055248.Among other things, the HIG includes a SIP “Back-to-Back User Agent”(B2BUA) for interworking between SIP enabled but non-IMS enabled devicesand the IMS network. The B2BUA is equipped with an ISIM application andhandles IMS signalling on behalf of SIP devices, such that allsignalling concerning an SIP device is associated with the correspondingIMPI on the ISIM application. For example, an SIP enabled device maysend an SIP REGISTER message to the HIG, containing only an SIPidentity. The HIG will then translate the message into an IMS REGISTERmessage that contains both an IMPI and an IMPU, according to regular IMSprocedures.

A typical scenario for using a HIG is generally outlined in FIG. 2,illustrating a private or “home” environment 200, such as a familyresidence or an office, that contains a plurality of differentcommunication devices linked together in a private network 202. Asillustrated here, these devices may include a wireline telephone, acordless telephone, a TV set, a server and a PC, and these will besimply referred to as “devices” hereafter.

The private network 202 includes a conventional residential gateway RGW204 which is connected to an external access network 206, providing acommunication link for media M to and from the devices in network 202.Although not specifically illustrated here, the RGW 204 typicallyincludes NAT (Network Address Translation) and firewall functions, andalso a local DHCP (Dynamic Host Configuration Protocol) server providingprivate IP addresses to the devices, as is well-known in the art.

The private network 202 further includes an HIG 208 providing aconnection to an IMS network, here illustrated as an IMS core 210containing an HSS 212, among other things. The HIG 208 is equipped withinterfaces towards the different types of devices for signalling, usingdevice-specific protocols. In the patent application PCT/EP2005/055248,the basic functional architecture of HIG, including various interfaces,protocol translation and gateway functions, is described in detail.However, these configuration specifics are not necessary to describehere further in order to understand the present invention.

In practice, the described HIG functionality may be implemented as aseparate node, or in an RGW, or even in an IMS enabled terminal. Whenthe HIG 208 is implemented as a standalone node connected to the privatenetwork 202, signalling to/from the IMS network 210 is actually alsorouted through the RGW 204. Although the HIG is shown here as a unitseparated from RGW, it typically operates “behind” the RGW andterminates the signalling traffic, as indicated by dashed lines in thefigure. However, for simplicity, the HIG will generally be considered asa separate functional unit in the following description, regardless ofimplementation.

In the HIG 208, identity information 214 is stored for each of thedevices in the network 202, typically including the above-mentionedIMPU, which is valid for accessing the IMS core 210 where the sameidentity information is also stored as subscriber information 216 in theHSS 212, as indicated in the figure. The patent applicationPCT/EP2005/055248 outlines how different combinations of IMPI and IMPUcan be used in this context. Thus, each device in network 202 has beenassigned a valid IMS identity, e.g. including an IMPU, which isassociated with its local IP address. The identity information 214 istypically stored in an ISIM application implemented in the HIG 208.

Thus, when a device in network 202 sends a request for a multimediaservice, using a protocol within its capability, the HIG 208 identifiesthe device by means of its local IP address, and retrieves the IMSidentity 214 associated with that device. Then, the HIG can translatethe received service request and create a valid SIP-based IMS request(e.g. SIP INVITE) on behalf of the device, using the retrieved IMSidentity 214. HIG 208 will then set up a session for the device bycommunicating suitable SIP messages with the IMS core 210, accordingly.

In a similar manner, an incoming call involving an IMS service, that maybe addressed to one of the devices or generally to the private home oroffice, can be set up by the HIG on behalf of a device using an IMSidentity 214 associated with the device. The call can then be routed tothe called device over the RGW 204 to communicate media M. In this way,the IMS core will perceive the device in network 202 as an IMS enableddevice, and the device will use the HIG 208 as a proxy for accessingservices offered by means of the IMS network.

However, this procedure implies that a valid IMS identity must beassigned in the HIG for each device in the private network 202. The IMSnetwork operator typically hands out IMS identities which also must beregistered in the IMS network as subscriber information stored in theHSS 212. Each time a device is added to the network, a new IMS identitymust be assigned thereto. Consequently, the IMS identity setup at bothlocations 208, 212 must be modified each time a device is added orremoved from the local environment, i.e. the private network 202.

This somewhat inflexible solution places an unwanted administrationburden on the user as well as the IMS operator, and it is not evidenthow a user should handle the IMS identities, e.g. IMPU's. Moreover, theIMS network may become loaded with numerous IMS identities andcorresponding subscriptions that must be managed, e.g. forauthentication. A more flexible and convenient solution is thusdesirable for providing access to IMS services for non-IMS enableddevices.

SUMMARY

It is an object of the present invention to address at least some of theproblems outlined above. More specifically, it is an object of thepresent invention to make it possible to avoid management of specificpublic identities for each device in a private network, when providingaccess to multimedia services.

These objects and others can be obtained by providing a method and anarrangement in a multimedia service gateway according to the independentclaims attached below.

According to one aspect, the present invention encompasses a method ofproviding access to multimedia services for communication devicesconnected to a private network, by means of a multimedia gatewayconnected to a multimedia service network. When a request is receivedfrom a device in the private network for a public identity associatedwith the multimedia gateway, an associated public identity is selectedand allocated to said device from a pool of public identities associatedwith the multimedia gateway which have been predefined as valid in themultimedia service network. Then, the device is registered by activatingthe allocated associated public identity in the multimedia servicenetwork, thereby enabling the multimedia gateway to establish amultimedia session on behalf of said device, using said allocatedassociated public identity.

The associated public identities in the pool may include temporaryidentities for use by any devices and/or users in the private network,and personal identities reserved for use by specific devices and/orusers in the private network. If a personal associated public identityis required, a specific associated public identity reserved for saiddevice and/or its user may be selected, whereas if no personalassociated public identity is required, any available temporaryassociated public identity may be selected.

In the inventive method, the received identity request may indicatewhether a personal or temporary associated public identity is desired.Alternatively, a personal associated public identity may beautomatically required when the identity request was received from aparticular device or user. The associated public identities in the poolmay have been predefined in the multimedia service network for differentservice profiles with respect to any of: service access limitations,bandwidth priorities, QoS control, parental control, pricingnegotiations, identity of calling/called party, black listing, andsecurity enforcement.

In the inventive method, the received identity request may be aspecifically adapted message defined in said device as an explicitrequest for an associated public identity. If the device is an SIPenabled device, the received identity request may be either aspecifically adapted SIP message, or a regular SIP request message for amultimedia service interpreted as an implicit request for an associatedpublic identity.

The selected associated public identity may be saved together withidentity information on said device in a session database. The deviceidentity entered in the session database for the device may include aninternal identity code and/or a local IP address of the device.

Selecting and allocating an associated public identity from the pool mayinclude identifying the requesting device and/or user and applyingpredetermined allocation rules or policies to the request, based on theidentified device and/or user.

The multimedia service network may be an IMS network and the associatedpublic identities in the pool may be IMPU's. The inventive method may beexecuted in a separate node, or in an RGW, or in an IMS enabled terminalin the private network, depending on the implementation of themultimedia gateway.

According to another aspect, the present invention further encompassesan arrangement in a multimedia gateway connected to a multimedia servicenetwork, for providing access to multimedia services for communicationdevices connected to a private network. The inventive arrangementbasically comprises a communication unit and an identity manager. Thecommunication unit is adapted to receive a request from a device in theprivate network for a public identity associated with the multimediagateway. The identity manager is adapted to select and allocate to saiddevice, an associated public identity from a pool of public identitiesassociated with the multimedia gateway which have been predefined asvalid in the multimedia service network. The communication unit isfurther adapted to register the device by activating the allocatedassociated public identity in the multimedia service network, therebyenabling the multimedia gateway to establish a multimedia session onbehalf of said device, using said allocated associated public identity.

In the inventive arrangement, the associated public identities in thepool may include temporary identities for use by any devices and/orusers in the private network, and personal identities reserved for useby specific devices and/or users in the private network. If a personalassociated public identity is required, the identity manager may befurther adapted to select a specific associated public identity reservedfor said device and/or its user. On the other hand, if no personalassociated public identity is required, the identity manager may befurther adapted to select any available temporary associated publicidentity.

In the inventive arrangement, the received identity request may indicatewhether a personal or temporary associated public identity is desired.Alternatively, a personal associated public identity may beautomatically required when the received identity request was receivedfrom a particular device or user.

In the inventive arrangement, the associated public identities in thepool may have been predefined in the multimedia service network fordifferent service profiles with respect to any of: service accesslimitations, bandwidth priorities, QoS control, parental control,pricing negotiations, identity of calling/called party, black listing,and security enforcement.

In the inventive arrangement, the received identity request may be aspecifically adapted message defined in the device as an explicitrequest for an associated public identity. If the device is a SIPenabled device, the received identity request may be a specificallyadapted SIP message or a regular SIP request message for a multimediaservice, interpreted as an implicit request for an associated publicidentity.

The identity manager may be further adapted to save the selectedassociated public identity together with identity information on saiddevice in a session database. The device identity entered in the sessiondatabase for the device may include an internal identity code and/or alocal IP address of the device.

The identity manager may be further adapted to identify the requestingdevice and/or user, and apply predetermined allocation rules or policiesto the request, based on the identified device and/or user.

In the inventive arrangement, the multimedia service network may be anIMS network and the associated public identities in the pool may beIMPU's. The inventive arrangement in the multimedia gateway may beimplemented in a separate node, or in an RGW, or in an IMS enabledterminal in the private network.

Further possible features and benefits of the present invention will beexplained in the detailed description below.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described in more detail by means ofpreferred embodiments and with reference to the accompanying drawings,in which:

FIG. 1 is a schematic view of a conventional network structure forcommunicating multimedia between two communication terminals, accordingto the prior art.

FIG. 2 is a schematic view of a residential network with access tomultimedia services by means of a local multimedia gateway or “Home IMSGateway HIG”.

FIG. 3 is a block diagram including a multimedia gateway or HIG whenused for assigning an associated public identity to a device, inaccordance with one embodiment.

FIG. 4 is a block diagram illustrating the multimedia gateway or HIGshown in FIG. 3 when used for setting up a multimedia session for anoutgoing call, in accordance with another embodiment.

FIG. 5 is a block diagram illustrating the multimedia gateway or HIGshown in FIGS. 3 and 4 when used for registering a device with amultimedia service or IMS network.

FIG. 6 is a flow chart with steps in a procedure for assigning anassociated public identity to a device, in accordance with anotherembodiment.

DESCRIPTION OF PREFERRED EMBODIMENTS

Briefly described, the present invention enables multimediacommunication for any multimedia-capable communication device connectedto a private network, by means of a plurality of public identitiesassociated with a multimedia gateway, hereafter referred to as“associated public identities”, the multimedia gateway being defined asa subscriber in a multimedia service network. The associated publicidentities in the multimedia gateway may be either “temporary” or“personal”, here implying that temporary identities can be used more orless randomly by any devices and/or users in the private network,whereas personal identities are reserved for specific devices and/orusers in the private network. Thus, the temporary identities are sharedby all devices and users in the private network, although a temporaryidentity can of course be used by only one device at a time.

All the associated public identities are predefined as valid in themultimedia service network, and may be used as a “pool” of associatedpublic identities in the multimedia gateway. Thus, associated publicidentities may be selected from the pool and allocated to devicesdesiring to access multimedia services.

When providing access to multimedia services for a specific deviceand/or person by means of an associated public identity selected fromthe pool, that device/person will not be known to the multimedia servicenetwork which will only “see” the multimedia gateway as a subscriber.Thereby, privacy and anonymity can be preserved, and the behaviour ofthat particular device/person cannot be detected.

Thus, in response to an identity request from a device in the privatenetwork, an associated public identity is selected from the associatedpublic identity pool for temporary assignment to that device. Theselected associated public identity is also registered in the servicenetwork as valid for an (unknown) active device behind the multimediagateway. The activated associated public identity can then be used bythe multimedia gateway for accessing the service network on behalf ofthe device in the private network. The service network is typically anIMS network and the associated public identities are typically IMPU's.

By using a pool of associated public identities for a plurality ofdevices connected to the private network, it is not necessary to have afixed specific individual public identity for each device to obtainaccess to multimedia services. Thereby, it is sufficient to define themultimedia gateway as a subscriber with the multimedia service network,including its associated public identities, to cater for plural devicesin the private network, which will reduce the number of subscriptions inthe service network. Moreover, it is possible to allow a visiting devicetemporarily attached to the private network, to access the multimediaservices by assigning an associated public identity thereto. The trueidentity of the device will also be hidden behind the multimediagateway, thereby providing for privacy. Further advantages will becomeapparent in the following detailed description of embodiments of thepresent invention.

In this description, the multimedia gateway will be referred to as anHIG (Home IMS Gateway) connected to an IMS (IP Multimedia Subsystem)network. However, the present invention is basically not limited tothese specific terms, nor to any specific protocols and standardsreferred to in the following.

FIG. 3 illustrates a multimedia gateway or HIG 300 when used forallocating an associated public identity, such as IMPU, in accordancewith one embodiment. Similar to FIG. 2, the HIG 300 is a gateway betweena plurality of devices 302 in a private network and a multimedia servicenetwork, here indicated as an IMS core 304 in which an HSS 306 containssubscriber information. As described above, the HIG 300 may beimplemented as a separate node, in an RGW (not shown), or in an IMSenabled terminal (not shown).

It is assumed that the shown devices 302 are non-IMS enabled, just asdescribed above for FIG. 2, although the present invention does notexclude the use of IMS enabled devices as well. In this example, atelephone A, a PC B and a television set C are shown. The HIG 300 isprovided with suitable communication protocols and interfaces adapted tothe connected devices, each typically including both a hardwareinterface and a software interface, e.g. with protocol adapters (notshown here) for protocol translation, if needed. In the case of non-SIPdevices, protocol adapters may be used for UPnP (UniversalPlug-and-Play) or H.323, etc.

The HIG 300 comprises a communication unit 308 connected to the devices302, and an identity manager 310 configured to handle the assignment ofassociated public identities to devices, to be described in more detaillater below. The identity manager 310 could be referred to as a “DynamicIMPU Assignment Service, DIAS” when IMPU is used as a valid associatedpublic identity in the IMS network, although the more generic term “IDmanager” will be used in this description hereafter.

The ID manager 310 includes an allocation unit 312 for allocatingassociated public identities, a database or pool 314 with availableassociated public identities, hereafter referred to as ID pool, and asession database 316 for holding session information includingcombinations of devices and their assigned associated public identities.The ID pool 316 thus contains a plurality of temporary or personalassociated public identities ID₁, ID₂, ID₃, . . . that can be selectedfor device assignment. These associated public identities are known andpredefined in the IMS network 304, and are stored as subscriber data inthe HSS 306, as indicated by the dashed box therein and the dashedconnection line to the pool 314.

The associated public identities in the pool 314 may be predefined inthe IMS network for different service profiles with respect to, e.g.,certain service access limitations, bandwidth priorities, QoS control,parental control, pricing negotiations, identity of calling/calledparty, black listing, security enforcement, etc. Thereby, the identitiescan be allocated “intelligently” depending on, e.g., various rules orpolicies defined in the private network for different devices and/orusers.

In this example, communication unit 308 is shown having a plurality ofdifferent communication interfaces 1,2,3 . . . towards the devices 302,including a first interface 308 a adapted for non-SIP enabled terminals,and a second interface 308 b adapted for SIP enabled terminals. Asmentioned above, each interface includes a hardware interface and asoftware interface. Referring to FIG. 3, a procedure will now bedescribed for allocating associated public identities to devices 302 inthe private network. It is assumed that device A is a non-SIP enabledterminal and connected to the first interface 308 a, whereas device B isan SIP enabled terminal and connected to the second interface 308 b. Theinterfaces 308 a, 308 b may be entered at different ports in thecommunication unit 308.

In a first step 3:1, a request for an associated public identity isreceived in communication unit 308 from device A over the firstinterface 308 a. This identity request is a specifically adapted newmessage defined in device A as an explicit request for a validassociated public identity, in order to gain access to multimediaservices from the IMS network 304. It may be required that the device Ais authenticated in the HIG at this point, which however lies outsidethe scope of the present invention and is therefore not necessary todescribe here further.

In a shown alternative first step 3:1(B), a request for an associatedpublic identity may be received from device B instead over the secondinterface 308 b. Being an SIP enabled terminal, this identity requestmay be a regular SIP request message for some multimedia service, andnot an explicit request for a valid associated public identity as in theformer case. In this context however, this message can be interpreted bythe ID manager 310 as an implicit request for a valid associated publicidentity, in order to gain access to multimedia services from the IMSnetwork 304. Thereby, it is not necessary to define and implement anynew message to this effect for SIP enabled devices connected to thesecond interface 308 b. Alternatively, device B may be configured tosend a specifically adapted new SIP message as an explicit request for avalid associated public identity.

In either case, reception of this (explicit or implicit) request of step3:1 or 3:1(B) results in that communication unit 308 sends a suitableinternal trigger message to the allocation unit 312, in a step 3:2,triggering allocation of an associated public identity for device A (orB). In response thereto, allocation unit 312 selects a suitable validassociated public identity from the identity pool 314, in a further step3:3. As mentioned above, associated public identities can be allocated“intelligently” which may be dictated by predetermined rules or policiesfor different devices and/or users. Thus, the allocation unit may applya predetermined allocation algorithm or the like implementing such rulesor policies.

For example, if device A requires a personal associated public identity,a specific associated public identity reserved for that device and/oruser is selected, whereas if no personal associated public identity isrequired, any available temporary associated public identity may berandomly selected. In one embodiment, the user may optionally indicatein the identity request of step 3:1 whether a personal or temporaryassociated public identity is desired. In the case of SIP devices, anextension of SIP may be required to implement this option.Alternatively, a personal associated public identity may beautomatically required when the request is sent from a particular deviceor user.

When an associated public identity, e.g. IMPU, has been selected fromthe identity pool 314 for device A (or B), the selected associatedpublic identity is saved together with identity information on thedevice A (or B) in the session database 316, in a step 3:4. In thefigure, session database 316 indicates that identity ID_(x) has beenallocated to device A and identity ID_(y) has been allocated to deviceB. The device identity entered in session database 316 for device A (orB) may include some internal identity code and/or a local IP address ofthe device.

In a next step 3:5, allocation unit 312 informs communication unit 308on the allocated associated public identity of device A (or B) by meansof a suitable internal message. In response thereto, communication unit308 sends a registration request to IMS core 304 in a final step 3:6, inorder to activate the associated public identity allocated for device a(or B), such that the HIG 300 can obtain multimedia services from IMScore 304 on behalf of device A (or B) using that identity.

Using the scenario and elements outlined in FIG. 3, FIG. 4 illustrateshow a multimedia session can be established for device A, in this casebeing a calling party. The same numerals are used here for correspondingelements. The devices in the private network are further connected to aconventional network gateway, here referred to as a “Residential GatewayRGW” 400, which in turn is connected to an access network 402, for thecommunication of media. Although not specifically illustrated here, theRGW 204 typically includes NAT (Network Address Translation) andfirewall functions, and also a local DHCP (Dynamic Host ConfigurationProtocol) server providing private IP addresses to the devices, as iswell-known in the art.

In the HIG 300, only communication unit 308 and session database 316 areshown, and it is assumed that an associated public identity ID_(x) hasbeen allocated to device A, as indicated within session database 316. Inorder to establish multimedia sessions, it may be necessary to usefurther information on the devices, e.g. regarding their current status,settings and capabilities with respect to multimedia communication,which may also be stored (not shown) in the HIG 300.

In a first step 4:1, communication unit 308 in HIG 300 receives asession request from the device A directed to a remote party (notshown), e.g. an IMS enabled terminal or a content server. The receivedrequest is given according to a protocol used by device A over theabove-described first interface, not shown here.

In a next step 4:2, communication unit 308 retrieves the associatedpublic identity ID_(x) allocated for device A from the session database316. Device capabilities, identity information and local IP address ofthe device A may also be retrieved at this point.

The communication unit 308 now communicates with the RGW 400 in order togenerally establish a communication link for device A, in a next step4:3. This step may include the reservation of a port opening in theNAT/firewall of RGW 308 for one or more different media streams of thesession. The RGW thus provides its public IP address on the accessnetwork side and the reserved port which is also associated with thelocal IP address of device A. This information will further beassociated with a Call ID defining the session, to be given duringsession setup.

The communication unit 308 then sets up a session on behalf of device Atowards the IMS core 304, using the retrieved identity ID_(x), in a nextstep 4:4. In this step, conventional signalling messages are exchangedwith the IMS network, typically according to SIP. For IMS services, thefirst message in the setup procedure would typically be an SIP INVITEmessage. Information including the associated public identity ID_(x) aswell as capability data of the device A, if available, may be providedto the IMS core 304 in an SDP message embedded in the SIP INVITEmessage.

Next, the communication unit 308 requests the RGW 400 to open thereserved port mappings in the NAT, including the finally negotiatedparameters such as the remote party's IP address, in a step 4:5.Finally, the session may begin in a step 4:6, and any incoming media cannow be mapped by the NAT in the RGW 400 to the local IP address and portof device A. A Call ID given during session setup of step 4:4, is alsostored in the HIG 300, for further reference during the session.

FIG. 5 illustrates how valid associated public identities can beimplemented in an HIG 300, by means of the above-described IMS PrivateIdentity IMPI and IMS Public Identity IMPU typically used in IMSnetworks. According to the current standard, the required IMS identityfor a subscriber comprises an IMPI and one or more associated IMPU's,but the present invention is generally not limited in this respect.Again, the same numerals indicate corresponding elements as in previousfigures. Thus, FIG. 5 shows a device A, an IMS core 304 and an ID pool314 within the HIG 300.

The HIG 300 has a main IMS identity 500, comprised of a combination ofan IMPI and a default IMPU, here indicated as IMPU_(HIG), valid in theIMS core 304 and stored as a subscription in an HSS 306 therein. The HSSfurther stores subscriber and authentication data, associated with themain IMS identity 500. In addition, a plurality of further IMPU's havebeen predefined for the subscription that can be used by differentdevices, which is possible, e.g. as described in the background sectionfor FIG. 2. These further IMPU's are stored in ID pool 314, containing aset of temporary IMPU's 502 and a set of personal IMPU's 504. Differentservice profiles may have been defined for different IMPU's in the HSS306, as described above. In this example, IMPU₂ has previously beenallocated to device A.

Thus, the HIG 300 has been defined in the IMS network 304 as asubscriber equivalent to any IMS-enabled communication terminal, suchthat the IMS network basically perceives the HIG as a single IMSsubscriber. Any non-IMS enabled devices capable of multimediacommunication may then use the subscription of the HIG 300, once theyare locally registered with the HIG. The subscription of HIG 300comprises all associated public identities 500, 502 and 504 as beingvalid in the IMS network. When IMPU's are gradually allocated todifferent devices in the private network, these IMPU's are registered or“activated” in the IMS core 304, e.g. as follows:

First, when the HIG 300 is powered-on or similar, an HIG registrationstep 5:1 is performed based on the main IMS identity 500, asschematically indicated by a first dashed arrow. Among other things, theHIG registration involves an authentication procedure e.g. according tosome conventional routine. In particular, the IMPI part of the main IMSidentity 500 is typically used for authentication of the HIG 300.

Then, in response to receiving a service request from device A asillustrated by a step 5:2, a device registration step 5:3 is performedbased on the allocated IMPU₂, as schematically indicated by a seconddashed arrow. It should be noted that no specific device authenticationprocedure is necessary during the device registration of step 5:3, sincethe authority of HIG 300 is utilised, as established in the earlier step5:1. However, the IMS network may request a re-authentication of HIGduring a device registration, but that would be terminated in HIG,making any re-authentications transparent to the device A. Thereby, HIG300 can establish a multimedia session on behalf of device A,schematically indicated by a following step 5:4, e.g. as described abovefor FIG. 4.

FIG. 6 is a flow chart illustrating different steps for allocating anassociated public identity to a device in a private network, using anidentity manager in a multimedia gateway, in order to provide access toa multimedia service network (typically an IMS network). The illustratedprocedure is generally executed in the identity manager, such as the IDmanager 310 described for FIG. 3 above, and may be performed in aseparate node, or in an RGW, or in an IMS enabled terminal in theprivate network, depending on the implementation of the multimediagateway. It is assumed that a plurality of associated public identities,e.g. IMPU's, have been defined for the multimedia gateway in themultimedia service network, including reserved and temporary identities,which are valid in the multimedia service network.

In a first step 600, a request for a valid associated public identity isreceived from a device in the private network, which may be either anexplicit or implicit request as described above. In a next step 602, therequesting device and/or user is identified and predetermined allocationrules or policies are applied to the request, based on the identifieddevice and/or user.

In a next step 604, it is determined whether the device or user requiresa personal associated public identity or not. As mentioned above, it maybe up to the user to request for a personal or temporary associatedpublic identity, or the type of identity may be selected automatically,depending on the implementation. If a personal identity is required, anassociated public identity is selected for allocation in step 606 thathas been reserved for the requesting device and/or user. If not, one ofthe temporary associated public identities is selected for allocation instep 608.

In a final step 610, the device is registered with the service networkusing the allocated associated public identity, just as in step 5:3 ofFIG. 5.

As compared to using of a HIG as described in the background section,the present invention provides for great flexibility in the allocationof associated public identities for any devices capable of multimediacommunication in a private network, optionally based on predefined rulesor policies. The present invention may result in a reduced number ofassociated public identities, IMPU's in particular, that must be definedfor terminals in the multimedia service network, since identities froman ID pool can be reused for different users and/or devices. The networkoperator will thus benefit from the management of fewer publicidentities, such as IMPU's, and its associated subscriber andauthentication data.

Further benefits may include increased privacy, since devices usingpublic identities associated with the multimedia gateway will not bediscernable to others outside the private network. In other words,neither the network operator nor other users can detect individualdevice identities and their properties and activities. The efforts formanual configuration, including registration of devices in themultimedia service network, can also be minimised. A user can thuscreate a private network with “hidden” devices using associated publicidentities, which are not necessary to register individually in themultimedia service network for specified devices.

It is further possible to introduce temporary visitors in the privatenetwork, without involving the multimedia service network, which thencan obtain access to multimedia services offered by the multimediaservice network, using the HIG and its associated public identities.Thus, it is entirely up to the private network user if a visiting deviceshould be allowed to access the multimedia services in this way.

While the invention has been described with reference to specificexemplary embodiments, the description is in general only intended toillustrate the inventive concept and should not be taken as limiting thescope of the invention. For example, the concepts of IMS and HIG havebeen used throughout when describing the above embodiments, although anyother standards and network elements for enabling multimediacommunication may basically be used. The present invention is defined bythe appended claims.

1. A method of providing access to multimedia services for communication devices connected to a private network, by means of a multimedia gateway connected to a multimedia service network, comprising the following steps: receiving a request from a device in the private network for a public identity associated with the multimedia gateway, selecting and allocating to said device an associated public identity from a pool of public identities associated with the multimedia gateway which have been predefined as valid in the multimedia service network, and registering the device by activating the allocated associated public identity in the multimedia service network, thereby enabling the multimedia gateway to establish a multimedia session on behalf of said device, using said allocated associated public identity.
 2. A method according to claim 1, wherein the associated public identities in said pool include temporary identities for use by any devices and/or users in the private network, and personal identities reserved for use by specific devices and/or users in the private network.
 3. A method according to claim 2, wherein if a personal associated public identity is required, a specific associated public identity reserved for said device and/or its user is selected, whereas if no personal associated public identity is required, any available temporary associated public identity is selected.
 4. A method according to claim 2, wherein said received identity request indicates whether a personal or temporary associated public identity is desired.
 5. A method according to claim 2, wherein a personal associated public identity is automatically required when said identity request was received from a particular device or user.
 6. A method according to claim 1, wherein the associated public identities in the pool have been predefined in the multimedia service network for different service profiles with respect to any of: service access limitations, bandwidth priorities, QoS control, parental control, pricing negotiations, identity of calling/called party, black listing, and security enforcement.
 7. A method according to claim 1, wherein the received identity request is a specifically adapted message defined in said device as an explicit request for an associated public identity.
 8. A method according to claim 7, wherein said device is a SIP enabled device and the received identity request is a specifically adapted SIP message.
 9. A method according to claim 1, wherein said device is an SIP enabled device, and the received identity request is a regular SIP request message for a multimedia service, interpreted as an implicit request for an associated public identity.
 10. A method according to claim 1, wherein the selected associated public identity is saved together with identity information on said device in a session database.
 11. A method according to claim 10, wherein the device identity entered in the session database for said device includes an internal identity code and/or a local IP address of the device.
 12. A method according to claim 1, wherein said selecting and allocating step includes identifying the requesting device and/or user and applying predetermined allocation rules or policies to the request, based on the identified device and/or user.
 13. A method according to claim 1, wherein the multimedia service network is an IMS network and the associated public identities in the pool are IMPU's.
 14. A method according to claim 1, performed in a separate node, or in an RGW, or in an IMS enabled terminal in the private network.
 15. An arrangement in a multimedia gateway connected to a multimedia service network, for providing access to multimedia services for communication devices connected to a private network, comprising: a communication unit adapted to receive a request from a device in the private network for a public identity associated with the multimedia gateway, and an identity manager adapted to select and allocate to said device, an associated public identity from a pool of public identities associated with the multimedia gateway which have been predefined as valid in the multimedia service network, wherein the communication unit is further adapted to register the device by activating the allocated associated public identity in the multimedia service network, thereby enabling the multimedia gateway to establish a multimedia session on behalf of said device, using said allocated associated public identity.
 16. An arrangement according to claim 15, wherein the associated public identities in said pool include temporary identities for use by any devices and/or users in the private network, and personal identities reserved for use by specific devices and/or users in the private network.
 17. An arrangement according to claim 16, wherein if a personal associated public identity is required, said identity manager is further adapted to select a specific associated public identity reserved for said device and/or its user, whereas if no personal associated public identity is required, said identity manager is further adapted to select any available temporary associated public identity.
 18. An arrangement according to claim 16, wherein said received identity request indicates whether a personal or temporary associated public identity is desired.
 19. An arrangement according to claim 16, wherein a personal associated public identity is automatically required when said received identity request was received from a particular device or user.
 20. An arrangement according to claim 15, wherein the associated public identities in the pool have been predefined in the multimedia service network for different service profiles with respect to any of: service access limitations, bandwidth priorities, QoS control, parental control, pricing negotiations, identity of calling/called party, black listing, and security enforcement.
 21. An arrangement according to claim 15, wherein the received identity request is a specifically adapted message defined in said device as an explicit request for an associated public identity.
 22. An arrangement according to claim 21, wherein said device is a SIP enabled device and the received identity request is a specifically adapted SIP message.
 23. An arrangement according to claim 15, wherein said device is an SIP enabled device, and the received identity request is a regular SIP request message for a multimedia service, interpreted as an implicit request for an associated public identity.
 24. An arrangement according to claim 15, wherein said identity manager is further adapted to save the selected associated public identity together with identity information on said device in a session database.
 25. An arrangement according to claim 24, wherein the device identity entered in the session database for said device includes an internal identity code and/or a local IP address of the device.
 26. An arrangement according to claim 15, wherein said identity manager is further adapted to identify the requesting device and/or user and apply predetermined allocation rules or policies to the request, based on the identified device and/or user.
 27. An arrangement according to claim 15, wherein the multimedia service network is an IMS network and the associated public identities in the pool are IMPU's.
 28. An arrangement according to claim 15, adapted to be implemented as a separate node, or in an RGW, or in an IMS enabled terminal in the private network. 